1. Field of the Invention
This specification relates to systems and methods for the provision of audiovisual information, and in particular to a system and method for providing a compressed packetized transport (CPT) stream such as moving picture experts group (MPEG) compliant streams to a device via a live streaming protocol.
2. Description of the Related Art
Compression technologies have made the storage and transmission of media programs having audiovisual information to consumers feasible. Such video compression techniques (hereinafter generically referred to as compressed packetized transport (CPT) techniques typically break the media program into a plurality of frames that are compressed using spatial and/or temporal encoding techniques. Typically, some of the frames are identified as index (or I) frames, which are only spatially encoded also known as Intra-coded. Such frames can be decoded without requiring data from any of the other frames, and serve as a datum for other frames. Other frames (known as predictive or P-frames) also use temporal compression techniques, wherein the data recorded for the frame represent changes from an earlier frame. Since frame-to-frame differences are often small, such frames are substantially more efficiently compressed than the I-frames. P-frames, however, cannot be decoded without reference to another (e.g. I) frame. Still other frames (known as bi-predictive or B-frames) also use spatial and temporal compression, but obtain their values from multiple frames. B-frames offer higher compression than I-frames or P-frames, but must reference those frames to be reproduced. MPEG-2, MPEG-3, MPEG-4, H.264, H.265, and AVC are examples of CPT paradigms.
Compressed media programs can be transmitted via satellite, cable, terrestrial wireless transmission, or the Internet, or received in analog form and compressed locally. Once received by a suitable device such as a set top box (STB) or receiver, the media programs may be decoded and/or decrypted (if encoded and/or encrypted by the headend or source of the media program) and provided to a display device for presentation to the user.
Such media programs may also be locally recorded for later playback using devices such as a digital video recorder (DVR), which may be integrated with the receiver or a separate device. Such recordings are typically stored on a large capacity storage device such as a hard disk drive (HDD).
DVRs typically include a first-in-first-out (FIFO) buffer that stores media programs as they are received and plays them back a short time later, subject to user control. This provides a “live pause” capability that allows the user to pause the playback of the received media program, with the FIFO buffer continuing to store received data as it is received. When the user thereafter selects “play,” playback from the FIFO is resumed. The FIFO buffer is typically implemented by the same hard disk drive (HDD) used to permanently store media programs, as though separate memory devices may be used.
Many customers desire media programs to be provided for display in more than one place in their homes. In the past, this has required use of a plurality of receivers, one in each location where service is desired. This requires the use of additional expensive hardware, and also the installation of cabling within the home that is suitable for high throughput data transmission. However, recent years have seen the emergence of Gateway receivers that receive media programs and provide them to a plurality of display devices located throughout the home. Since such transmission is of typically lower bandwidth, cabling of reduced transmission throughput or wireless transmission becomes feasible.
Transmission from a gateway receiver can be performed either via simple downloading, progressive downloading or streaming. Simple downloading transfers a media file of data to the remote playback device in any convenient (and not necessarily temporal) order, hence the client typically cannot begin playback of the media program until the entire media file has been received. Progressive downloading transmits data at the temporal beginning of a media file and continues downloading the file sequentially and consecutively until completed at the temporal end of the media program. Playback can commence once sufficient information has been downloaded to support playback.
Streaming delivers media content continuously for concurrent and immediate playback by the device. Unlike progressive downloading, streaming media can be delivered on-demand or live. Streaming also allows the viewer to navigate any point in the media program (even to a temporal point after the current playback position) via navigation requests received from the media player. Streaming paradigms can also adaptively respond to changes in the transmission channel bandwidth. Some paradigms accomplish this via messaging between the media player and the server.
HLS (HTTP Live Streaming) is a type of streaming protocol typically used with mobile devices such as QUICKTIME or iOS compliant devices. HLS operates by breaking a media program down into a number of smaller HTTP-transmittable media files sometimes known as “chunks” that are to be provided to the media player. A manifest or playlist is generated and provided to the media player before playback begins. The playlist indicates the appropriate temporal sequence of the chunks, and the address where the chunks may be obtained from the device serving them, such as a gateway receiver. Chunks may be generated with transcoding parameters that are appropriate for different transmission and display systems (e.g. different frame rates, resolutions, and scan paradigms), thus resulting in multiple chunks that represent the same temporal portions of the media program (albeit, with different frame rates, resolutions, or scan paradigm). The appropriate sequence and address of such chunks may also be provided, permitting the media player to adapt to changing transmission channel bandwidth by simply requesting the appropriate chunks.
However, for gateway applications, the transcoding parameters are critical to the user experience. Generally, the chunks created under the HLS protocol are of varying temporal length. This can result in chunks that are of as much as 10 seconds or more, which affects the user experience when attempting to navigation or trick play operations (e.g. fast forward, skip, reverse), as navigation can only generally be performed to a particular chunk, not within a chunk. HLS also does not guarantee that a chunk will be defined that has an index or I-frame. This is not particularly problematic, so long as the media player receives and decodes all of the data without errors. But if the media player loses sufficient data because of transmission channel or other problems, the media player will not be able to recover and continue decoding the media stream until it receives another I-frame. If a chunk were 10 seconds or more in temporal length and lacked an I-frame, that would result in a significant gap in the media program as presented by the media device. It is possible transcode the media stream so as to include more I-frames, but this results in compression inefficiencies for the reasons described above, and this still does not guarantee that there is an I-frame in each chunk. It is also possible to define chunks to be of very short temporal duration, but doing so increases the size of the playlist and how often it must be updated. Further, very small chunk sizes may affect attempts to measure the channel performance, as the transmit time of groups of data may be disguised by other factors, hence of little use.
Accordingly, there is a need for improved methods and systems for transcoding CPT data into HLS-compliant and similar protocols. The present invention satisfies that need.